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rated network branch that has been cut off from piablic ac- 
cess. As a consequence, transport quality along a dedicated 
path through a network might change over time quite fre- 
quently and significantly. 

5 

Hence, existing QoS-sensitive flows have to be rapidly estab- 
lished, restored, adapted and released in response to wire- 
less impairments as well as topology changes. As described in 
the article „A Framework for Bidirectional QoS Signaling'^ 

10 (Internet Draft, 2002) by M. Shahrier and K. M. Shaheen, 
this problem counteracts the principle to support real-time 
conversational applications, e,g. voice-over- IP (VoIP) or 
videoconferencing, with performance requirements similar to 
those of existing circuit-switched or voice-abased wired and 

15 wireless systems because all these symmetric streaming serv- 
ices impose stable symmetric bidirectional resoxirce require- 
ments, e,g, bandwidth and latency characteristics. 

The complexities of existing protocols often do not meet 

20 these requirements. Service architectures have been proposed 
to enable resource • reservation for an individual data flow 
(e.g. file exchange with an ftp server) , namely the Inte- 
grated Services (IntServ) model. Alternatively, the Differen- 
tiated Service (DiffServ) model has been proposed to improve 

25 scalability by determining packet forwarding behavior on ag- 
gregates of flows with less state inforroation required in 
network nodes along the routing path. The resource reserva- 
tion protocol • (RSVP) as one candidate of the IntServ model 
• has been proposed to enable an application to spontaneously 

30 signal resource demands to a peer host . The protocol may be 
interpreted hop-by-hop along the routing path or tunneled 
transparently to a non-RSVP network region with appropriate 
mapping mechanisms in place at the network boundaries of the 
non-compliant region. Though the RSVP protocol has gained 

35 some acceptance in IP- related research and standardization 
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communities, deficiencies of the protocol become obvious when 
it has to interoperate with adaptive real-time applications 
in mobile environments. Even ongoing standardization to ex- 
tend RSVP (as. investigated in IETF WG NSIS) can not suffi- 
5 ciently compensate the described networking problems since a 
clear separation between control and user data does not allow 
fast adaptation to changed networking conditions. 

At the local level, ad-hoc networks that link notebook or 

10 palmtop computers could be used to spread and share informa- 
tion among participants of a conference- They might also be 
appropriate for applications in home networks where devices 
c^n commvmicate directly to exchange information, such as 
audio and/or video signals, alarms, and configuration up- 

15 dates. Perhaps the most far-reaching appldcations in this 
context are more or less autonomous ^networks of inter- 
connected home robots that clean, do dishes, mow the lawn,, 
perform security surveillance, and so on. Recently, ad-hoc 
mult i -hop networks were proposed for environmental monitor- 

20 ing, in which said networks could be used to forecast water 
pollution or provide early warnings of an approaching tsu- 
nami. Short-range ad-hoc networks can simplify intercommuni- 
cation between various mobile devices (e.g. cellular phones 
and PDAs) by forming a so-called „ Personal Area Network" 

25 (PAN) , thereby eliminating the need for cables. This could 
also extend the mobility provided by fixed networks to nodes 
of an ad-hoc network domain. 

Typically, mobile ad-hoc networks (MANETs) operate with dis- 
30 tributed functions and allow traffic to pass over multiple 
radio hops between a source and a destination. Routing algo- 
rithms and the implications of radio layers are challenging 
research areas for these networks.- The inherent unpredict- 
ability in a network whose nodes move poses a challenge to 
35 routing and mobility functions if data is consistently trans- 
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f erred between the nodes of the underlying network. Nonethe- 
less, mult i -hop radio systems also make it possible to save 
battery capacity while retaining performance. In any case, 
the most attractive property of an ad-hoc networking model is 
5 perhaps its independence from centralized control and, thus, 
the increased freedom and flexibility it gives the user. 

BRIEF DESCRIPTION OP THE PRESENT STATE OP THE. ART 

10 In order to understand the central idea of * the invention, it 
is necessary to briefly explain some of the most important 
QoS reservation concepts and protocols according to the state 
of the art. 

15 As described in the article ^Network Element Service Specifi- 
cation Template*' (IETF RFC 2216, September 1997) by S. 
Shenker and J, Wroclawski, various QoS reservation concepts 
are offered to mobile users today. The term „ quality of seirv- 
ice'* (QoS) refers to the nature of the provided packet deliv- 

20 ery service, which is described by parameters such as the 
currently achieved bandwidth, packet delay, packet loss 
rates, etc. Traditionally, the Internet offers a single-QoS, 
best-effort delivery, in which the available bandwidth and 
delay characteristics depend on the instantaneous load. The 

25 control over QoS seen by applications is exercised by an ade- 
quate provisioning of the underlying network infrastructure. 

For QoS-enabled IP-based networks, there are two main service 
streams, namely Integrated Services (IntServ) with its accom- 

30 panying signaling (Resource) Reservation Setup* Protocol 
(RSVP) and differentiated services (DiffServ) as described in 
the article „An Architecture for Differentiated Services" 
(IETF RFC 2475, Dec. 1998) by S. Blake, D. Black, M. Carlson, 
E. Davies, Z. Wang, and W. We.iss . The IntServ architecture 

35 mentioned ed^ove defines a set of extensions to the tradi- 
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tional best-effort (BE) model of the Internet with the object 
to provide applications with end-to-end QoS . Said differenti- 
ated services provide an aggregation of reservations for 
similar QoS data flows without any signaling. Therefore, 
5 DiffServ networks classify packets into one out of a small 
number of aggregated QoS data flows or classes", based on 
the so-called DiffServ Code Point (DSCP) , 

For a QoS architecture a packet classifier is used to clas- 
10 sify packets into a flow or sequence of packets that should 
be treated in a specified way, e.g. as proposed by the Int- 
Serv architecture, which is described in the article 
Integrated Services in the Internet Architecture: An Over- 
views^ (IETF RFC 1633, June 1994) by R. Braden et al . For this, 
15 purpose, a reservation identifier is required to uniquely 
identify an application flow, A reservation identifieir can 
comprise several packet fields, e.g. IP source, destination 
IP address, port numbers etc. For IPv6, as described in the 
„ Internet Protocol, Version G {IPv6) Specification'' (IETF RFC- 
20 2460, December 1998) by S. Deering and R. Hinden, a flow la- 
bel field has been defined to simplify classification of in- 
dividual flows. There have been proposals to evaluate this 
field together with the IPv6 sender source address for vmique 
identification of a flow. 

25 

As described in the articles „Resource Reservation Protocol 
(RSVP) - Version 1: Functional Specification^* (IETF RFC 2205, 
September 1997) by R. Bradon et al*, the concept of „soft 

30 state** is used by the resource reservation protocol (RSVP) , 
which uses periodic refresh message sent along the data path 
to maintain the connection alive • Thereby RSVP is an 
end-to-end control protocol, which forms the signaling part 
of the integrated services architecture. The reservation is 

35 receiver -oriented, and the aggregation of said reservations 
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is supported depending on the needs of the respective appli- 
cation. A QoS data flow may have multiple senders, and the 
protocol supports different reservation styles to dictate how 
to aggregate reservations for different senders. Two impor- 
5 tant message types used by RSVP are „PATH" and ,,RESV" • Each 
data source periodically sends a ,/PATH" message that sets up 
the path state at the routers along the path from the sender 
to the receiver. The receiver of each QoS data flow periodi- 
cally sends a „RESV" message, which sets up a reservation 
10 state at intermediate routers along the reverse path from the 
receiver to the sender. Thereby, RSVP assumes a fairly stable 
path across the network. 

The Mobile Resource Reservation Protocol (MRSVP) as de- 
15 scribed in the article „MRSVP: A Resource Reservation Proto- 
col for an Integrated Services Network with Mobile Hosts" 
(Department of Computer Science, Technical Report, DCS-TR- 
337, Rutgers University, USA, July 1997) by A* K. Talukdar, 
B. R. Badrinath and A. Acharya supports two types of reser- 
20 vations: active and passive reservations: An active reserva- 
tion corresponds to a QoS data flow over which data is actu- 
ally exchanged, whereas a passive reservation books re- 
sources in advance still to be used by other data flowsthat 
might require weaker QoS guarantees or best-effort services. 

25 

SHORTCOMINGS AND PROBLEMS OP THE PRIOR-ART SOLUTIONS 

One' of the most significant problems within an ad-hoc network 
is that the routing path of a data flow and the QoS condi- 

30 tions of a communication connection might change over time 
quite frequently and significantly. Therefore, the data flow 
possibly has to be rapidly redirected, restored, adapted and 
released in response to wireless environment impairments and 
topology changes. Nowadays, the prevailing QoS protocols ac- 

35 cording to the state of the art are not well suited to such a 
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dynamic mobile wireless environment. Instead of proactively 
probing the QoS situation of the potential future routing 
path, they react in a more passive and reactive way to the 
QoS condition changes caused by handover processes. 

5 

Typically, conventional resource reservation protocols such 
as RSVP only support unidirectional reservation requests. A 
solution, which has been discussed so far for symmetric ap- 
plications is the unbundled bidirectional reservation* 

10 Thereby, two unidirectional connections are established from 
opposite .communication endpoints („ application peers'^) . For 
routing nodes along the path both reservations have no inter ^ 
dependence since the upstream flow has no relationship to its 
associated downstream traffic in the sense of routing re^ 

15 strict ions. These unpredictable asymmetries could e.g. lead 
to the situation that the overall QoS needs for a conversa-- 
tional connection are not longer sufficient although one di- 
rection of the connection would have still sufficient capa- 
bilities. In mobile wireless networks where the link quality 

20 may frequently vary over time there is a requirement for spe- 
cific types of bidirectional applications to „bundle^* the 
routes in each direction. Thereby, both directions should 
follow the same route or should be treated as a single in- 
stance by the network. 

25 

Whilst transport- and network- layer QoS have been studied 
within the Internet for many years, these works are mainly 
based on the assumption of a wired network. Wireless communi- 
cation within a multi -homed heterogeneous access network 

30 where mobile nodes have to deal with wireless link connec- 
tions, however, is characterized by restricted bandwidths, 
increased error rates and resource fluctuations. In addition, 
when mobile nodes change their point of access to the net- 
work, mechanisms are needed to control the behavior of the 

35 system during and after a handover. Hence, wireless QoS pro- 
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visioning becomes more relevant to deal with this inherent 
behavior of these unreliable networks • Taking conversational 
real-time applications into account which run on the mobile 
node, such . as voice-over-IP (VoIP) or videoconferencing, the 
5 requested QoS capabilities are similar to those of existing 
circuit -switched or voice -based wireless systems as described 
in the article „A Framework for Bidirectional QoS Signaling" 
(Internet Draft, 2002) by S. M. Shahrier and K. M. Shaheen. 

10 These symmetric streaming services demand stable symmetric 
bidirectional bandwidth and latency conditions • The need of 
bidirectional reservations is also evident within TCP connec- 
tions where the throughput is reduced if acknowledgment mes- 
sages, are delayed or lost on the backward path. 

15 

Fig. 1 gives an example where, an application flow, generated 
in the mobile node, can be routed between two alternative 
ways to get connected to the access network. In contemporary 
IP transport networks there is no restriction on the down- 

20 stream and the upstream flow to follow different paths on the 
physical network. Thus, QoS .reservations are not bidirec- 
tional due to asymmetric IP routing for both directions . This 
situation can cause problems in mobile wireless streaming 
real-time scenarios where the application relies on symmetric 

25 capabilities along the commixnication path. 

In contrast to the wired world, these capabilities are unpre- 
dictable over the time in the mobile wireless case. This can 
lead to the situation where the uplink is not longer able to 

30 support the requested QoS parameters and, on the other hand, 
the downlink has not been affected by any wireless link qual- 
ity changes. These asymmetries eould imply that the overall 
QoS needs for bidirectional connections are not longer suffi- 
cient although the path of one direction would still have 

35 sufficient resources. 
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OBJECT OF THE PRESENT INVENTIOisr 

In view of the explanations mentioned above, it is the object 
of the invention to propose an effective QoS mechanism in ad- 
hoc network environments. 

This object is achieved by means of the features of the inde- 
pendent claims. Advantageous features are defined in the de- 
pendent claims. Further objects and advantages of the inven- 
tion are apparent in the detailed description, which follows. 

SUMMARY OP THE INVENTION 

The proposed solution of the present invention is dedicated 
to a mechanism for a bidirectional QoS reservation procedure 
within an in-band signaling mechanism that gives symmetric- 
real-time services running on mobile devices, which are used.- 
to support different access technologies in dynamic, mobile,,- 
wireless IP networks where the quality of the node connectiv- 
ity can sometimes be unpredictably time-varying, the possi- 
bility to mutually reserve, monitor and/ or adapt QoS re- 
sources and service parameters for up- and downstream direc- 
tion along a communication path. The proposed solution 
thereby optimizes conventional QoS reservation mechanisms ac- 
cording to the. state of the art, especially for adaptive 
real-time services in wireless networks and wireless ad-hoc 
networks by making use of a dynamic bidirectional QoS reser- 
vation in-band signaling approach based on dynamic bidirec- 
tional bundled network resource reservations. The technical 
term „ in-band" thereby refers to a situation where separation 
between control data and user plane data is abandoned. 
Thereby, both communication directions may not be independent 
from the perspective of the network. Fig. 2 shows a cotnmuni- 
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cation scenario example where up^ and downlink are forced to 
use the same communication path. 

m the following section, a number of prerequisites for the 
proposed solution according to the. invention with respect to 
Qos monitoring, reservation management and the applied soft 
state model shall briefly be described. 

- Qos monitoring: The QoS framework should be able to monitor 
the actual QoS capabilities on the data link layer (layer 
2). It shall be assumed that an adaptive application is 
regularly supplied with up-to-date information about net- 
work resource availability along the QoS^enabled path 
Therefore, an in-band signaling mechanism is proposed that 
provides optimal support for adaptive applications. 

- Reservation management: The data link layer must be able to 
process QoS requests generated by the QoS model, e.g. pas- 
sive or active resource reservation requests. 

- soft state model: In wireless networks, the reservation 
initiator which is used to keep the reserved connection 
alive should be able to periodically refresh network state 
information, which is described by a soft state reservation 



25 model 



in general, a reservation may be unidirectional or bidirec- 
tional. The initiator of a reservation request thus provides 
resource reservation information by means of „QoS information 
elements", which are embedded in a „QoS container-. 

The proposed in-band signaling approach is correlated with a 
flexible resource reservation mechanism, which provides res- 
ervation features for a wide range of applications. This con- 
cept enables a client or server application to specify its 
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reservation style requirements such that these fit best to a 
given service or business model. The resource parameters are 
specified in the ,,QoS information elements"* included in the 
^,QoS container". 

5 

A possible implementation is to integrate the ^QoS container** 
into the IPv6 hop-by- hop extension header, which is described 
in the article „ Internet Protocol, Version 6 (IPv6) Specifi- 
cation** (IETF RFC 2460, December 1998) by S. Deering and R. 
10 Hinden. The reservation „QoS container** is composed in modu- 
lar fashion. For example, an application can include those 
parameters that are necessary from a set of pre^^fined val- 
ues . 

15 The specification of ;,QoS information elements** offered to an 
application has major impacts on the resource usage of the 
network. More precisely, these information elements influence 
the timing of reservation, the control over it and other is- 
sues . 

20 

In order to provide efficient usage of resources among multi- 
ple flows, it is recommended to establish network policies, 
which define the permissible circumstances for applying spe- 
cific „QoS information elements**. Reservation adaptivity, 

25 i.e. the ability to adapt to changed conditions in the net- 
work, is not a reservation style parameter to be indicated to 
the IP layer. It is assumed that adaptivity is agreed on be- 
tween flow terminating .nodes, which take into account the 
currently available resources offered by the IP and lower 

30 layers . 

A concept is introduced to allow fast reservation, which hap- 
pens on one ipass without confirmation. Alternatively, reser- 
vation may be triggered by the aclcnowledgment traveling to- 
35 wards the initiator of the request. Therefore, the concept of 
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active and passive reservation is introduced. It has been de- 
rived from MRSVP, which supports these two types of reserva- 
tions . 

For a passive reservation a flow can declare its demand of 
network resources e.g. a certain amount of bandwidth for po- 
tential future use. These .^passive reserved^^ resources can be 
used by any other flows until the status of the reservation 
is changed to active reservation. Therefore, passively re- 
served resources can be borrowed by other flows. In this way, 
network utilization in networks with alternating conditions 
can be improved. Passive state reservation may be used in ad- 
vance to a planned handover as well . 

An active reservation is exclusively assigned to a specific 
flow or flow aggregate with well-defined QoS capabilities for 
data packet exchange. No other flow can share allocated re- 
sources except the one who made the active reservation. The 
active reservation is also defined as soft state and has 
therefore to be refreshed • 

A unidirectional reservation can be considered as a fallback 
solution in case a bidirectional resemration cannot be estab- 
lished or has to be released. In this case, datagrams between 
two communication peers do not necessarily travel along the 
same path due to asymmetric links or load distribution. 

Compared to RSVP, where only unidirectional reservation re- 
quests are supported, in this approach the possibility to re- 
quest for a bidirectional reservation is introduced. For a 
bidirectional reservation it is assumed * that upstream and 
downstream reservation between two-peer hosts use the same 
path through the network in opposite direction. A bidirec- 
tional data flow represents an atomic instance that combines 
resource reservations in opposite directions along the same 
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palth. The bidirectional path may be established hop-by-hop or 
by means determining an explicit route list. To support sym- 
metric and asymmetric reservations, a separate set of reser- 
vation metrics and monitoring fields for the forward and re- 
verse direction has to be considered for a protocol implemen- 
tation. 

To establish a reservation, an independent probing mechanism 
has to test both uplink and downlink network paths. Each hop 
has to check for available resources for outgoing and incom- 
ing interface and possibly reserve (passive or active) re- 
sources for both interfaces before forwarding the request to 
the next hop router from the initiator perspective. 

The feedback about the result of the bidirectional reservaV 
tion establishment process can be stored within the „ actual 
value" field. The application, while receiving the monitoring 
information of the researvation setup, is in charge of decid- 
ing how to react to the reservation result. 

Today's state of the art routing nodes do not support a res- 
ervation for both directions in a single step. In case a 
routing node does not support bidirectional reservation 
setup, the result of a partially failed reservation will be 
stored within the according monitoring field (e.g. in case of 
the QoS metric within the „ actual value" field) . Within this 
process the initiator will be notified that only one direc- 
tion of the reservation request could, be established and 
therefore a bidirectional reservation request could not be 
fulfilled. 

Asymmetric network load may also cause the failure of a bidi- 
rectional reservation setup. In case of failure the initiator 
has the responsibility to decide how to deal with the situa- 
tion of insufficient resources. One reaction scheme could be 
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that the initiator requests only a unidirectional reserva- 
tion. By receiving only a unidirectional reservation, the 
peer has the responsibility to establish the downstream' res- 
ervation by itself. 

In case the resource probing mechanism detects that upstream 
and downstream paths for a bidirectional reservation do not 
follow identical routes at a specific routing node along the 
reservation path, some or all monitored attribute values car- 
ried in the IP datagram header are set to zero at the respec- 
tive node. Dependent on the syntax specification of the res- 
ervation protocol those attribute values should be set to 
zero that enable the reservation endpoints to easily inter- 
pret the situation of routing asymmetry. Fig. 3 shows the de- 
cision path for a bidirectional reservation setup. 

When a bidirectional reservation is timed out or explicitly 
removed, both upstream and downstream reservations entries 
are removed. 

The advantages of the present invention consist in the per- 
formance of a dynamic bidirectional resource reservation, 
which can be achieved in a single step, a combined reserva- 
tion monitoring and adaptation of two directions and an in- 
band signaling concept which can suitably be applied to mo- 
bile environments. 

- Dynamic bidirectional resource reservation: Particular ap- 
plications-, which presume a bidirectional communication 
path could benefit from bidirectional reservations. Both 
communication directions may not be independent from the 
perspective of the application, in wireless networks where 
the link quality may frequently vary over time there is a 
requirement for specific types of applications to „bundle« 
the routes in opposite direction, which means that both di- 



P 28362 EP 



15 



rections should follow the same route or should be treated 
as a single instance by the network. 

— Bidirectional resource reservation in one step: Resources 
5 may be allocated by a single message transmitted hop-by-hop 

between the initiator of a request and its corresponding 
node or alternatively by two messages (request and confir- 
mation) . For a bundled bidirectional reservation it is as- 
sumed that upstream and downstream reservation between two- 

10 peer hosts use the same path through the network in oppo- 
site direction. The invention thereby introduces the con- 
cept of a bidirectional flow as an atomic instance, which 
combines reservations in opposite directions along the same 
path. Bidirectional reservation bundling ensures signaling 

15 advantages by reducing the network^ signaling overhead. 

— Combined reservation monitoring and adaptation of two di- 
rections: Independent probing mechanisms are needed to test 
both uplink and downlink network paths. Each hop has to 

20 check for available resources for outgoing and incoming in.- 

terface and possibly reserve the resources for both inter- 
faces before forwarding the request to the next hop router 
from the initiator perspective. Bidirectional monitoring or 
adaptation of resources is carried out within a single mes- 

25 sage. In case of handover situations and QoS adaptation, 
flow bundling may speed up the renegotiation process. 

— In-band signaling concept for mobile environments: In-band 
signaling is most beneficial for the bidirectional biondled 

30 reservation over network links with unpredictable charac- 
teristics. The signaling overhead is considerably small for 
a regular bidirectional flow. For example, said signaling 
information can be piggybacked by application datagrams if 
these are sent regularly within the configured soft state 

35 time interval. The host, which represents the reservation 
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end point, generates feedback information of the reserva- 
tion. As there is no application data transmitted to the 
reservation initiator, provisioning of this feedback infor- 
mation induces some problems for a unidirectional' applica- 
5 tion flow. For a reliable transport connection (e.g, TCP) 
there is still a bidirectional message flow, which can be 
used to carry feedback information to the initiator of the 
reservation. If there is no bidirectional flow, said feed- 
back information may be placed in an IPv6 datagram with no 
10 other purpose. However, it has to be considered that this 
procedure imposes additional signaling load to the network. 

One embodiment of the invention pertains to a bidirectional 
quality-of -service (QoS) reservation method for reserving, 

15 allocating, monitoring and/or adapting network resources and/ 
or service parameters needed for symmetric real-time multime- 
dia applications and/or data services running on a mobile 
node and a correspondent node by signaling resource control 
information in both directions along specific routing paths 

20 between these nodes through an IP-based dynamic mobile ad-hoc 
network which comprises a number of interconnected forwarding 
nodes whose connectivity is unpredictably time-varying. Re- 
source control information to be transmitted between the mo- 
bile node and the correspondent node is embedded in an IP da- 

25 tagram which is sent hop-by-hop via the routing path of the 
reserved connection for these nodes, and resource control in- 
formation is disseminated between the mobile liode and the 
correspondent node by using the same routing path through the 
network hop-by-hop in both directions. 

30 

Thereby, either the mobile node or the correspondent node 
initiates a resource reservation request message indicating 
the demand for a predefined amount of network resources si- 
multaneously for both directions. The initiator of the reser- 
35 vat ion request and the initially proposed amoixnt of network 
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resources for the reservation are defined by an agreement or 
contract which has been established between the communicating 
peers. Alternatively, . both parties arrange an agreement by 
means of a session- or application- layer negotiation. 

5 

According to the invention, the initiator of the resource 
reservation request message generates a unique reservation 
identifier (ID) associating the. bidirectional connection with 
a single application flow or an aggregated flow for IP data- 

10 gram classification in both directions to achieve a specific 
'forwarding behaviour which remains unchanged during the life- 
time of the associated flow. Thereby, network resources are 
allocated or monitored hop-by-hop by using resource control 
information piggy-packed in an IP datagram, or both is done 

15 at the same time for both directions of the resource reserva- 
tion request message, wherein resource control information 
for both directions of the preserved routing path is embedded 
in the same IP datagram. 

20 Resource control information for each direction of a reserva- 
tion is piggybacked via resource information elements that 
are a part of the header extension of the IP datagram, 
wherein each resource information element represents either a 
resource attribute along the reserved routing path, associ- 

25 ated with a quantifiable resource metric for either one or 
both directions of the flow, or a flow attribute for an indi- 
vidual flow or flow aggregate, associated with quantifiable 
and non- quantifiable flow context information either for one 
or both directions of the flow. 

30 

Thereby, said resource information elements describe resource 
control information for upstream direction from the initiator 
towards the receiver or downstream direction from the re- 
ceiver towards the initiator of a resource reseirvation re- 
35 quest message or for both directions together, wherein up- 
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Stream and downstream direction are uniquely identified by 
the mobile node and the correspondent node due to their role 
in the reservation procedure either as initiator or receiver 
of a resource reservation request message. 

The resource information elements are organized in a modular 
fashion for each flow, which means that the node that origi- 
nates the resource • control information determines the number 
of resource information elements to be placed into an IP da- 
tagram header. 

Each resource information element comprises a field for the 
monitored attribute value and attribute requirement specifi- 
cation fields specifying resource-attribute-specific flow re- 
quirements, which are described by an upper threshold defin- 
ing the maximum value and/or a lower threshold defining the 
minimum value for the respective resource attribute. Alterna- 
tively or in addition, discrete values for the respective re- 
source attribute can be specified. The attribute requirement 
specification can be generated and modified either by the 
initiator or the receiver of the reservation and can be in- 
terpreted by routing nodes along the reservation path to al- 
locate the requested amount of resources. 

According to a further embodiment of the present invention, 
information about available resources for both directions of 
the reservation along the reserved routing path between the 
mobile node and the correspondent node are simultaneously 
monitored. For every node along the reserved ■ routing path, 
actual resource attribute values for up- and downstream di- 
rection are determined. If at any node along the reserved 
routing path a monitored resource attribute either for up- or 
downstream direction or for both directions has a value which 
is less than the correspondent monitored attribute value that 
is carried in the IP datagram header, the new value is as- 
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signed to the resource information element of the IP datagram 
header, which enables the receiver of the resource control- 
information to determine current resource values for both di- 
rections . 

5 

According to a still further embodiment of the present inven- 
tion, a resource reservation request message describing a set 
of attribute requirement specifications is sent from the ini- 
tiator to the receiver, and the resource allocation procedure 

10 either for one or both directions of the resource reservation 
is controlled by either the mobile node or the correspondent 
node. Based on. such a resource reservation reqpiest message, 
resource attribute values that should be allocated for the 
upstream direction, the downstream direction or both direc- 

15 tions at the same time are determined by every forwarding 
node along the reserved routing path. Control of resources, 
for the bidirectional reservation is handled by the commiani- 
cating peers through higher layer negotiation. ■ In case of 
lack of higher-layer negotiation mechanisms, the communicat- 

20 ing peers can exchange information elements in specific IP 
extension headers that are interpreted end-to-end instead of 
hop -by- hop. 

Resource control information for different bidirectional 
25 flows is piggy-packed in the same IP datagram, wherein for 
each flow a reservation identifier information element refer- 
ring to additional flow and resource information elements in 
the header of the IP. datagram is attached to the IP datagram 
header and the grouping of reservation identifiers and other 
30 resource information elements deteirmines the membership of 
this information to a specific flow. Thereby, either the mo- 
bile node or the correspondent node determines on the IP 
layer whether bidirectional or unidirectional resource con- 
trol information can be inserted into an IP datagram that is 
35 ready to be transmitted to the networking interface or 
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whether a separate IP datagram needs to be generated for that 
purpose. Said resource control information is placed in any 
IP datagram which follows the reserved routing path between 
the initiator and the receiver of a resource reservation re- 
quest message . 

According to a further embodiment of the invention, condi- 
tions of insufficient resources along the routing path for 
upstream and downstream direction at the correspondent node 
are recognized by comparing monitored attribute values with 
the attribute requirement specifications in the resource in- 
formation elements, of an arriving IP datagram. .The method 
thereby avoids defining specific exception or alerting mes- 
sages. The addressed end system has to react to the lack of 
the specific resource. 

Monitored resource attribute values of specific resource in- 
formation elements specified in the IP datagram header are 
set to zero in case one or more forwarding nodes do not sup- 
port these resource attributes . 

One embodiment of the invention pertains to a bidirectional 
quality-of-service (QoS) reservation method which is charac- 
terized by the step of setting monitored attribute values 
carried in the IP datagram header at the respective node to 
zero that enable reservation end points to easily interpret 
the situation of routing asymmetry if up- and downstream path 
for a bidirectional reservation do not follow identical 
routes at a specific routing node along the reserved routing 
path. 

According to a further embodiment of the invention, resource 
reservation request messages with the value zero for one or 
more attribute requirement specifications are interpreted as 
explicit release messages by the forwarding nodes along the 
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reserved routing path and by the initiator or receiver of the 
resource reservation request messages. The values of these 
attribute requirement specifications are then associated with 
the removal of flow-specific reservation state information in 
5 the forwarding nodes along the reserved routing path. 

Resource reservation request messages with a value unequal to 
zero for one or more attribute requirement specifications are 
interpreted as explicit setup messages by the forwarding 

10 nodes along the reserved routing path and by the receiver of 
the resource reservation request messages. The values of 
these attribute requirement specifications are thjsn associ- 
ated with the installation of flow- specif ic reservation state 
information in the foirwarding nodes along the reserved rout- 

15 ing path. 

According to a still further embodiment of the invention, a 
flow infomtiation element specifying the type of reservation; 
as either bidirectional or unidirectional is piggy-packed in 
20 the IP datagram header of a researvation setup message. This 
flow information element is then interpreted at the forward- 
ing nodes along the reserved routing path to ensure correct 
installation of reservation state information. 

25 BRIEF DESCRIPTION OF THE DRAWINGS 

Further advantages and embodiments of the present invention 
result from the subordinate claims as well as from the fol- 
lowing detailed description of the invention as depicted in 
30 the accompanying drawings: 

Fig. shows an ovearview of a wireless bidirectional communi- 
1 cation scenario, wherein different paths are reserved 

for the up- and downlink connection, which gives an 
example where an application flow, generated in a mo- 
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bile node, can be routed between two alternative ways 
to get connected to an access network. 

Fig- shows an overview of a wireless bidirectional communi- 

2 cation scenario, wherein the same paths are reserved 
for the up- and downlink connection. 

Fig. is a flow chart which shows the bidirectional reserva-- 

3 tion setup procedure according to one embodiment of 
the present invention. 

Fig. illustrates an example for the structure of the QoS 

4 container of an IP datagram. 

Fig. illustrates an example of a modular QoS metric infor- 

5 mat ion element. 

Fig. illustrates an example of a modular QoS metric infor- 

6 mation element in an asymmetric bidirectional communi- 
cation scenario. 

Fig. illustrates an example of a modular QoS metric infor- 

7 mation element in a symmetric bidirectional communica- 
tion scenario. 

Fig. shows a communication example in a symmetric bidirec- 

# 

8 tional communication scenario with sufficient re- 
sources , and 

Fig. shows a communication example in a symmetric bidirec - 

9 tional communication scenario with insufficient re- 
sources . 
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DETAILED DESCRIPTION OF THE PRESENT INVENTION 

In the following, embodiments of the present invention as de- 
picted in Figs. 1 to 9 shall be explained in detail. Further- 
5 more, a brief survey of an exemplary message syntax for an 
in-band signaling protocol for bidirectional signaling ac- 
cording to the present invention shall be given. The meaning 
of the symbols, which are designated with reference numerals 
and signs in these figures can be taken from Table 2 . 

10 

In IPv6, optional Internet -layer information is encoded in 
separate headers, which may be placed between the IPv6 header 
and the upper- layer header in a packet. Signaling information 
is carried in the hop-by-hop options header if it has to be 
15 interpreted by all routing nodes along a routing path. For 
information, which just has to be transferred between peer 
nodes, the destination option header is used. 

According to an example of the present invention, the IPv6 
20 hop-by-hop extension header, which is defined in the article 
^Internet Protocol, Version 6 (IPv6) Specification'* (IETF RFC 
2460, December 1998) by S. Deering and R. Hinden, is used to 
transport resource control information to be interpreted by 
routing nodes along the path. The signaling information is 
25 piggy-packed on an IP datagram, which follows the data path 
of the reserved connection hop-by-hop. Thereby, the same com- 
munication path through the network is used hop-by-hop in 
both directions in order to disseminate signaling information 
between both communication peers . 

30 

To provide a modular concept, the term „QoS container^' is in- 
troduced. In general, a QoS container includes signaling in- 
formation in form of QoS information elements, which are usu- 
ally related to a single flow, but may be associated with a 
35 group of flows as well . A key concept of the approach is the 
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variable number and size of QoS information elements that are 
located within a packet: For example, only information that 
currently needs to be interpreted is carried in the con- 
tainer. There are mandatory QoS information elements and op- 
5 tional QoS information elements within a QoS container, 
wherein optional QoS information elements contain supplemen- 
tary information. 

One QoS information element representation is the QoS metric 

10 information element, which carries QoS metric information. A 
QoS metric information element consists of a field for the 
monitored attribute value and., further fields that specify re- 
source-attribute-specific flow requirements, i.e. the attrib- 
ute requirement specification. An upper threshold defining 

15 the maximum value or a lower threshold defining the minimum 
value for the respective resource attribute describes the at- 
tribute requirement specification. Alternatively, upper and 
lower threshold values can be specified together, which de- 
scribe an interval within which values for the respective re- 

20 source attribute are acceptable for the reservation. Alterna- 
tively or in addition, discrete values for the respective re- 
source attribute can be specified. The attribute requirement 
specification can be generated and modified either by the 
initiator or the receiver of the reservation- and can be in- 

25 terpreted by routing nodes along the reservation path to al- 
locate the requested amount of resources . 

. Each reservation- initiating node has to generate a unique 
reservation identifier. The bidirectional connection is asso- 
30 ciated with a single application flow or an aggregated flow. 
The reservation identifier keeps unchanged during the life- 
time of its associated flow and is used for IP datagram clas- 
sification in both directions to achieve a specific forward- 
ing behaviour. 

35 
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Another example shows the need for the independence of the 
flow identifier. When the receiver of a flow changes its role 
and starts replying to a session defined by a specific reser- 
5 vation identifier, the receiver can add its IPv6 address in 
the IPv6 packet header source address field. In this case, 
the combination out of source address and the flow label will 
not longer represent the origin reservation identifier. In- 
tervening nodes will not be able to correctly classify pack- 

10 ets, that belong to the flow. Therefore, when flow transpar- 
ency is required, a reservation identifier information ele- 
ment is needed to transport the origin reservation identifier 
information. Different suggestions of a modified specifica- 
tion for defining the 20-bit flow label field, such as the 

15 paper „A Modified Specification for Use of the IPv6 FLow La- 
bel for Providing Efficient Quality of Service Using hybrid 
Approach^^ (Internet Draft, Feb. 2002) by R. Banerjee et al . , 
are actually out of the scope of this invention. In' cdntrast 
to some of these suggestions, a static flow label is a:ssumed 

20 during the session lifetime. 

A packet classification identifier, which is described in the 
article „ Integrated Services in the Internet Architecture: An 
Overview^^ (IETF RFC 1633, June 1994) by R. Braden et al . , is 

25 used to classify packets into a flow or a sequence of packets 
which should be treated in a specified way. Therefore, the 
term ^reservation identifier^' is used to identify a unique 
flow. It is proposed that the reservation identifier is built 
out of the IPv6 sender source address (the • address of the 

30 flow-generating host) and the IPv6 flow label defined in the 
,,Internet Protocol, Version 6 (IPv6) Specification'' (IETF RFC 
2460, December 1998) by S. Deering and R. Hinden. This is not 
mandatory owing to the requirement that a reservation identi- 
fier should be independent of the flow identifier, the IP ad- 

35 dress of the QoS initiator, and the flow end points. Various 
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scenarios in the mobility area require this independence be- 
cause flows resulting from handoff might have changed end 
points etc. but still have the same QoS requirement as de- 
scribed by M. Brunner et al , in their article ' ^Requirements 
5 for QoS Signaling Protocols'' (Internet Draft, November 2002, 
draft-brunner-nsis^req-02 . txt) * 

In c^se flow transparency is required, a reservation identi- 
fier information element has to be used to transport the 

10 original reservation identifier information. To enable effi- 
cient IPv6 flow classification, the „ reservation identifier 
- information element'* can be build out of the • IPv6 flow label 
field and the IPv6 source address, which are located only in 
the IPv6 main header fields in fixed positions. In case- a. 

15 „ reservation identifier information element" has been speci- 
fied within a QoS container, the flow information in the IPv6 
header has to be ignored. Within a QoS container it has to be 
the first QoS information element - 

20 While RSVP uses a receiver-oriented reservation, the proposed 
solution is able to trigger sender- as well as receiver-based 
reservation requests. For a sender-based reservation (denoted 
as an upstream reservation) resources are allocated for the 
outgoing interface at each intermediate routing node. In con- 

25 trast to a receiver-based reservation, network resources are 
allocated at an incoming interface of a routing node. To have 
the possibility to distinguish in which, direction the reser- 
vation setup should be enabled, both communication peers need 
to agree on the ordering of resource control elements for up- 

30 stream and downstream direction. In order to hide this as- 
signment from intermediate routing nodes, a communication 
peer could change the sequence of upstream and downstream- 
related resource control information with respect to the or- 
dering of resource control information in the received IP da- 

35 tagram. 
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To support a bidirectional session with the capability to 
perform bidirectional media adaptation, a bidirectional QoS 
attribute is introduced that belongs to a unique reservation 
5 identifier. This bidirectional QoS attribute informs the 
routers that the reservations along the communication path 
should be set up for both directions. The feedback about the 
success of the bidirectional reservation can be derived from 
the monitoring result, which is indicated in the ^actual 

10 value** field. The assumption that a symmetric bidirectional 
request has been executed can be derived from the fact that 
only one QoS metric information element has been generated 
for the bidirectional reservation- In contrast to the symmet- 
ric bidirectional request, the asymmetric bidirectional cas4 

15 offers two QoS information elements with identical type iden-^' 
tifiers that are grouped in one QoS container. The first Qo^ 
information element will be interpreted as the one who de- 
scribes the forward flow and the second one as the one who. 
describes the reverse flow. Up- and downstream directions are 

20 defined from the QoS -initiating node point of view. 

Each QoS container can carry several QoS information ele- 
ments. The piggy-packed QoS container holds resource control 
information in an IP datagram. It is used to allocate re- 

25 sources hop-by-hop, monitor resources hop-by- hop or do both 
at the same time for both directions of the reservation. The 
concept of modular flexible QoS information elements offers 
the advantage to fulfill in a fine-grained manner the QoS 
needs of a specific application. Each QoS information element 

30 should follow the TLV (Type-Length-Value) foiroat. „Type" 
specifies the object data, „ length** the number in octets, 
whereas „ value** describes the data field. QoS information 
elements are processed in the order they appear. As an exam- 
ple shown in Fig. 4 the QoS information element 400a is proc- 

35 essed before the QoS information element 400b. 
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Fig. 5 illustrates an example of a QoS metric information 
element. Beside the general type and length fields there is' 
the object's data field, which is divided in three further 
5 fields. These fields hold the actual, minimum and maximum 
values for a specific QoS metric. In this example the last 
two fields hold the values describing the QoS needs for a 
specific application. The third field covers the information 
coming from the network to give the necessary feedback about 
10 the actual situation of the end-to-end link conditions. 
Therefore, this field is updated with the actual value of the 
QoS specific network metric for each hop. If the value is set 
to zero, no resources are reseirved for the considered metric. 

15 Fig. 6 shows one example of a QoS metric information element 
in an asymmetric bidirectional scenario, which means that the 
up- and downstream QoS metric requests are different. Both 
communication peers need to agree on the ordering of resource 
control elements to clearly identify resource situation for 

20 upstream and downstream direction. In order to hide this 
agreement between communication peers from intermediate rout- 
ing nodes, a communication peer could change the sequence of 
upstream and downstream related resource control information 
with respect to the ordering of resource control information 

25 in the received IP datagram. 

Fig. 7 illustrates one example of a QoS metric information 
element in a symmetric bidirectional scenario. Within a sym- 
metric bidirectional reservation request • up- and downstream 
30 QoS metrics are equal. In this case, only one QoS information 
element with the same type identifier is stored in the QoS 
container. 

Fig. 8 shows a communication example in a symmetric bidirec- 
35 tional scenario with sufficient resources. The mobile node 
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106a (MN) sends a symmetric bidirectional reservation recpaest 
(1) via the intermediate node 106b (IN) (2) to the correspon- 
dent node 106c (CN) . Thereby, the IN has sufficient resources 
to fulfill the bidirectional resource request that has been 
5 initiated by the MN. Therefore, the IN reserves 200 Kbit/s in 
each direction and forwards (2) the bidirectional reservation 
request to the CN. The CN has now the information that the 
reservation request has been succeeded. It replies (3) , ex- 
plicit or piggybacked, the result to the MN. In downstream 
10 direction the intermediate node 106b may interpret the reser- 
vation request again (4) . 

Fig. 9 shows a comm\inication example in a symmetric bidirec- 
tional scenario with insufficient resources. The mobile node 

15 106a (MN) sends a symmetric bidirectional researvation request; 
(1) via the intermediate node 106b (IN) (2) to the correspon-' 
dent node 106c (CN) . Thereby, the IN has insufficient re- 
sources to fulfill the bidirectional resource request initi^ 
ated from MN. The IN is only capable to reserve a bitrate of 

20 150 Kbit/s for the upstream direction. The actual value field 
is therefore changed from 200 Kbit/s to 150 Kbit/s. Node IN 
forwards (2) the updated bidirectional reservation request to 
the CN. The CN has now the information that the reservation 
request could not be fulfilled. It replies (3, 4), explicit 

25 or piggybacked, the result to the MN. It is now up to the as- 
sociated application running on the MN to react accordingly 
to the insufficient resource availability along the path. 
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Table 1: Definitions 



30. Sep, 



Technical Term 


Brief Explanation of the Technical Term 


Ad- hoc Computing 


Ad-hoc computing refers to an automatic dis- 
covery of general -purpose services adver- 
tised in a network. The discovery process 
can be based on predefined information about 
the respective service name and/ or type. 


Ad-hoc Networking 
• 


By contrast, ad-hoc networking means the 
discovery of automatic devices and the es- 
tablishment of connectivity among nearby de- 
vices in an unplanned, uiimanaged fashion. 
Therefore, a routing of/ messages can be ac- 
complished on the basis of a multi-hop tech- 
nique, in which routing fiinctionality is of- 
fered by most (i/ not even all) the nodes 
participating to .the ad-hoc network. 


Ad -hoc Networks 


An ad-hoc netwozik can be any network for mo- 
bile communica^iion devices established by 
using the ad-hoc networking mechanism as de- 
scribed above. For example, it can be an un- 
managed, unplanned network of fixed and/or 
moving intercommunicating computing devices. 


Assisted Ad-hoc 
Networks 


2^ assisted ad-hoc network can be any net- 
work of communication devices established by 
using the ad-hoc networking mechanism as de- 
scribed above, but under the assistance and 
control of a so-called network operator pro- 
viding AAA fiinctionality as well as value- 
added services . 


Downstream and Up- 
stream 


The . directional terms „ upstream'" and 
„ downstream^* are defined with respect to the 
direction of a data flow. The traffic direc- 
tion from a source terminal towards a desti- 
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Technical Term 


Brief Explanation of the Technical Term 




nation terminal is referred to as 
„ downs t r earn the traffic direction from the 
destination terminal towards the source ter- 
minal is referred to as „upstream^* . 


QoS Initiator 


This entity is responsible for initiating 
application- flow-based reservations along a 
network path by signaling a resource request 
to the network. The entity can be located in 
the end system but may also reside elsewhere 
in the network. In addition^ QoS provision- 
ing mechanisms local to , the entity might be 
executed if there is a. ^limitation in avail- 
able resources . / 


Reservation Aggre- 
gation 


Reservation aggreg^^tion occurs if multiple 
reservations emergring from different source 
terminals towards the same destination ter- 
minal can be merged to represent a single 
reservation. The merging node has- to agree 
on combining reservations based on config- 
ured networking policy or management deci- 
sions . 


Reservation Sender 
and Receiver 


A reservation sender is an upstream border 
router that originates reservation messages. 
A reservation receiver is defined as a down- 
stream border router that terminates reser- 
vation messages . 


Spont aneous 

Ad -hoc Networks 


These are traditional ad- hoc networks, 
wherein no assistance from anv niat-wriyir r^i^— 
erator is provided whatever happens. Eventu- 
ally, assisted ad-hoc networks can not keep 
up with spontaneous ad-hoc networks, when- 
ever the involved peers get out of coverage 
of any access networks . 
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Table 2; Depicted Features and their Corresponding Reference 

Signs 



No. 



100 



Technical Feature (System Component, Method Step) 



diagram showing an overview of a wireless bidirectional 
communication scenario, wherein different paths are re- 
served for the up- and downlink connection, which gives an 
example where an application flow, generated in a mobile 
node 106a, can be routed between two alternative ways to 
get connected to an IP transport network 102 



102 



wired core (IP transport) network, based on^ iPv6 



gateway between the wired core network 102 'and a wireless 



103 



network 104 



104 



dynamic mobile ad-hoc network compris^ing a number of in- 
terconnected intearmediate nodes lOSa-c, wherein the con- 
nectivity of these nodes is unpredictably time-varying 



105a-c 



wireless routers (foarwarding nodes) , interconnected via 
the mobile ad-hoc network 104 



106a 



mobile node, connected to a correspondent node 10 6c via at 
least one intermediate node 106b 



106b 



(in Fig. 8) intermediate node, connected to the wired core 
network 102 and/ or the wireless network 104 



(in Pig. 8) correspondent node of said mobile node 10 6a 



106c 



200 



diagram showing an overview of a wireless bidirectional 
communication scenario, wherein the same paths are re- 
served for the up- and downlink connection 



300 



flow chart showing the bidirectional reservation setup 
procedure according to one embodiment of the present in- 
vention 



diagram showing an example for the structure of the QoS 
container of an IP datagram 



400 



400a 



first resource (QoS) information element, stored in the 
QoS container 
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No. 


Technical Feature (System Component^ Method Step) 


400b 


second resource (QoS) information element, stored in the 
QoS container 


401a 


type field (length: 1 byte) of the first QoS information 
element 400a which is stored in the QoS container 


401b 


length field (length: 1 byte) of the first QoS information 
element 40 0a 


401c 


data field (length: 2 bytes) of the first QoS information 
element 40 0a 


401d 


data field (length: 4 bytes) of the first QoS information 
element 4 0 0a 


401a' 


type field (length: 1 byte) of the second pdS information 
element 4 0 0b which is stored in the QoS container 


401b' 


length field (length: 1 byte) of the second QoS informa- 
tion element 400b , 


401c' 


data field (length: 2 bytes) of the second QoS information 
element 4 0 0b 


401d' 


data field (length: 4 bytes) of the second QoS information 
element 400b 


500 


diagram showing an example of a modular QoS metric infor- 
mat ion element 


500D 


data field (length: 3 bytes) of the QoS metric information 
element 500 


501 


type field (length: 1 byte) of the QoS metric information 
element 50 0 


502 


length field (length: 1 byte) of the QoS metric informa- 
tion element 5 00 


503 


actual-value field (length: 1 byte) of the. QoS metric in- 
formation element 50 0 


504 


minimum- value field (length: 1 byte) of the QoS metric in- 
formation element 5 00 


505 


maximum- value field (length: 1 byte) of the QoS metric in- 
formation element 500 


600 


diagram showing an example of a modular QoS metric infor- 
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No. 


Technical Feature (System Component , * Method Step) 




mation element in an asymmetric bidirectional communica- 
uxon scenario 


601a 


type field (length: 1 byte) of the QoS metric information 
element 600 in case of an asymmetric bidirectional sce- 
nario, indicating the data type of data transmitted from 
the mobile node 106a to its correspondent node 106c 
(forward flow) 


601b 


length field (length: 1 byte) of the QoS metric informa- 
tion element 600 in case of an asymmetric bidirectional 
scenario, indicating the amount of data transmitted from 
the mobile node 106a to its correspondent /node 106c 
(forward flow) - / 


601c 


actual -value field (length: 1 byte) /of the QoS metric in- 
formation element 600 in the forward-flow case of the 
asymmetric bidirectional scenario, which contains a dis- 
crete value for the respective resource attribute 


601d 


maximum- value field (length: 1 byte) of the QoS metric in- 
formation element 600 in the forward- flow case of the 
asymmetric bidirectional scenario, which contains the up- 
per threshold value of said interval 


601e 


minimum- value field (length: 1 byte) of the QoS metric in-- 
formation element 600 in the forward- flow case of the 
asymmetric bidirectional scenario, which contains the 
lower threshold value of an interval within which values 
for the respective resource attribute are acceptable for 
the researvation 


601a' 


type field (length: 1 byte) of the QoS metric information 

element 600 in r^as?^ f5"F an a s'vrnm^at* "r"*! "K-i r1 -5 v^/^t- n i 

^ ^ www JLAX wi. ciiiX jf iiuiic* ^4. X JlJXvjL J. lOncL J. see — 

nario, indicating the data type of data transmitted from 
the correspondent node 10 6c to the mobile node 106a 
(reverse flow) 


601b' 


length field (length: 1 byte) of the QoS metric informa- 
tion element 600 in case of an asymmetric bidirectional 
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j scenario, indicating the amount of data transmitted from 

the correspondent node 106c to the mobile node .106a 
j (reverse flow) 


601c' 


actual-value field (length: 1 byte) of the QoS metric in- 
formation element 600 in the reverse-flow case of the 
1 asymmetric bidirectional scenario | 


J 601d' 
■ 601e' 


maximum-value field (length: 1 byte) of the QoS metric in- 
formation element 600 in the reverse-flow, case of the 
j asymmetric bidirectional scenario j 
minimum-value field (length: 1 byte) of the QoS metric in- 
formation. element 600 in the reverse-flow pase of the 
asymmetric bidirectional scenario . ' 


601a' ' 


type field (length. 1 byte) of the QoS metric information 
element 700 in case of a symmetric bidirectional scenario 


601b' ' 


length field (length: 1 byte) of the QoS metric informa- 

tion element 700 in case of a symmetric bidirectional sce- 
nario ) 


601c' ' 


actual-value field (length: 1 byte) of the. QoS metric in- 
f ormation element 700 in case of a symmetric bidirectional 
scenario 


601d' ' J 


maximum-value field (length: 3, byte) of the QoS metric in- 
formation element 700 in case of a symmetric bidirectional 
scenario ( 


1 601e' ' 1 
i ^ f\ ^ f 


minimum-value field (length: l byte) of the QoS metric in- 
formation element 700 in case of a symmetric bidirectional 
scenario 


700 ji 

|l 


dxagram showing an example of a modular QoS metric infor> 

(nation element in a symmetric bidir-eni'-ir^niai ^^rr.^..^^ 

e^jriiuu^uj. -»jj-uj.iecuionax communxcation 1 

scenario 


800 < 
] 

1 ' 


diagram showing a communication example in a symmetri"^ 

bidirectional communication scenario with sufficient re- 
sources 


900 ( 


iiagram showing a communication example in a symmetric 
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bidirectional communication scenario with insufficient re- 
sources 


SI 


step #1: embedding resource control information to be 
transmitted between the mobile node 106a and the corre- 
spondent node 106c in an IP datagram 400 which is sent 
lop-by-hop Via the routing path or tne reservea connect: xon 
for these nodes 106a+c 


S2 


step #2: disseminating resource control information be- 
tween the mobile node 106a and the correspondent node 106c 
by using the same routing path (alternative #1) through 
the network 104 hop-by-hop in both directions 


S3a/b 


step #3a/b: initiating a resource reservation request mes- 
sage indicating the demand for a predefined amount of net- 
work resources simultaneously for both directions by the 
mobile node .106a {S3a) or its correspondent node 106c 
(S3b) 


S4 


step #4: generating a unique reservation identifier (ID) 
associating the bidirectional connection with a single ap- 
plication flow or an aggregated flow for IP datagram clas- 
sification in both directions by the initiator 106a/c of 
the resource reservation request message to acnieve a spe- 
cif ic forwarding behavior wnicn remains uncnangea ciu.iring 
the lifetime of the associated flow 


S5 


step #5: hop-by-hop allocating network resources by using 
resource control information piggy-packed in an IP data- 
gram 400 


86 


step #6: hop-by-hop monitoring these network resources 


S7 


ot-ia-n it'? • nicicrvhackina resource control information for 
each direction of a reservation via resource information 
elements 400a+b which are a part of the header extension 
401c+d, 401c' +d' of the IP datagram 400, wherein each re- 
source information element 400a+b represents either a re- 
source attribute along the reserved routing path (alterna- 
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jtive #1), associated with a quantitiable resource "metric " 
for either one or both directions of the flow, or a flow 
attribute for an individual flow or flow aggregate, asso- 
ciated with quantifiable and non-quantifiable flow context 
information either for one or both directions of the flow 


SB 


step #8 : determining the number of resource inf or^Ji^ti^H 

elements 400a^.b to be placed into an IP datagram header 
401c+d, 401c'+d' by the node (I06a or 106c) which origi- 
nates the resource control information 


S9a 
S9b 


step #9a: simuicaneously monitoring inf ormation-^bSIIt 

available resources for both directions of thfe reservation 
along the reserved routing path (alternative #i) between 
the mobile node 106a and the correspondent ^ode I06c 




step #9b: aecermining actual resource attribute values for 
up- and downstream direction for every node 105b+c along 
the reserved routing path (alternative #1) •• * 


S9c 
S9d 


step #9c: If at any node 105b-.c alouy the reserved routing 
path (alternative #i) a monitored resource attribute ei- 
ther for up- or downstream direction or for both direc- 
tions has a value which is less than the correspondent 
monitored attribute value that is carried in the IP data- 
gram header, assigning the .new value to the resource in- 
formation element 400a/b of the IP datagram header 


IsiOa 1 


step #9d: determining current resource values tor both di- 
rections by the receiver. of the resource control informa- 
tion 


j 1 
SlOb L 


-L..^ #x^a: senamg a resource reservation request message 
describing a set of attribute requirement snec.-i f ^ 


1 
I 


step #l0b: controlling the resource allocation procedure " 
either for one or both directions of the resource reserva- 
-xon by either the mobile node 106a or the correspondent 
lode 106c 


SlOc £ 


>^ap ffioc: based on such a resource rese^ation-^^jlli^ 
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message, determining resource attribute values that should 
be allocated for the upstream direction, the downstream 
direction or both directions at the same time by every 
forwarding node 105b+c along the reserved routing path 

(alternative #1) 

sua (step #lla: piggy-packing resource control information for 
different bidirectional flows in the same IP datagram 400 
Sllb step #llb: attaching a reservation identifier information 
element referring to additional flow and resource informa- 
tion elements 40Ga+b in the header of the IP datagram 4 00 
to the IP datagram header for each flow j 

step #llc: determining the membership gf this information 
to a. specific flow by the grouping afc reservation identi- 
fiers and other resource information elements 400a+b 



S12 step #12: determining on the IP layer whether bidirec- 

tional or unidirectional resource control information can 
be inserted into an IP datagram 400 that is ready to be 
transmitted to the networking interface or whether a sepa- 
rate IP datagram 400 needs to be generated for that pur- 
|pose by the mobile node 106a or the correspondent node 

1 106c ^ 

|Si3a- [step #13a: recognizing conditions of insufficient re- 

j sources along the routing path for upstream and downstream] 
direction at the correspondent node 106c 



Si3b step #13b: comparing monitored attribute values with the 
attribute requirement specifications in the resource in- 
formation elements 400a+b of an arriving IP datagram 4 00 



IS14 step #14: setting monitored resource attribute values of 

j specific resource information elements specified in the IP 
datagram header 400 to zero in case at least one forward- 
ing nodes 150b+c does not support these resource attrib- 
utes 



L«-«r^ ttit;. fi^t-Hna those attribute values carried in the IP 
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datagram header to zero that enable reservation end points 
to easily interpret the situation of routing asymmetry if 
up- and downstream path for a bidirectional reservation do 
not follow identical routes at a specific routing node 
105b/c along the reserved routing path (alternative #1) 


S16a 


step »16a: interpreting resource reservation request mes- 
sages with the value zero for one or more attribute re- 
quirement specifications as explicit release messages by 
the forwarding nodes 105b+c along the reserved routing 
path (alternative #1) and by the initiator or receiver of 
the resource reservation request messages 


S16b 


step #16b: associating the values of these attribute re- 
quirement specifications with the rempval of flow-specific 
reservation state information in the forwarding nodes 
105b+c along the reserved routing path (alternative #1) 


S17a 


step #17a: interpreting resource reservation request mes- 
sages with a value unequal to zero for one or more attrib- 
ute requirement specifications as explicit setup messages 
by the forwarding nodes 105b+c along the reserved routing 
path (alternative #1) and by the receiver 106c of the re- 
source reservation request messages 


S17b 


step #17b: associating the values of these attribute re- 
quirement specifications with the installation of flow- 
specific reservation state information in the forwarding 
nodes 105b+c along the reserved routing path (alternative 
#1) 


S18a 


step #18a: piggy -packing a flow information element speci- 
fying the type of reservation as either bidirectional or 
unidirectional in the IP datagram header 401c+d, 401c' +d' 
of a reservation setup message 


S18b 


step #18br interpreting this flow information element at " 
the forwarding nodes 105b+c along the reserved routing 
path (alternative #1) to ensure correct installation of 
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reservation state information 


S301 


step #301: starting the resource probing mechanism 


S302 


step #302: in case query #301 yields „FALSE*^ or query #302 
yields „TRUE'\ setting the ,,actual value'' field for the 
backward direction within the QoS metric information ele- 
ment to zero and updating the „ actual value'* field 


S3 03 


step #3 03: processing the module ,,passive or active reser- 
vation" for the uplink network path 


S304 


step #304: in case query #302 yields „FALSE'\ updating the 
„ actual value'* fields for both directions within the QoS 
metric information element 


S305 


step #305: processing the module ^passive or Active reser- 
vation" for the uplink and downlink network paths 


Q301 


query #3 01: query whether the routing node supports a 
bidirectional reservation 


Q3 02 


query #302: in case query # 301 yields „TRUE", query 
whether the uplink and downlink network paths differ 
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Claims 

1. A quality-of -service (QoS) reservation method for managing 
network resources and/or service parameters needed for sym- 
metric real-time multimedia applications and/or data seirvices 
3running on a mobile node (106a} and a correspondent node 
(106c) by signaling resource control information along spe- 
cific routing paths between these nodes (106a, 106c) , 

said method comprising the steps of 

— embedding (SI) resource control information to be transmit- 
ted between the mobile node (106a) and the correspondent 
node (106c) in an message (400) which is sent via the rout- 
ing path of the reserved connection for these nodes 
(106a+c) and 

- disseminating (S2) resource control information between the 
mobile node (106a) and the correspondent node (106c) by us- 
ing the same routing path (alternative #1) through the net- 
work (104) ±n both directions. 

1 

2 . A method according to claim 1 , 
characterized in that 

the mobile node (106a) initiates (S3a) a resource reservation 
req[uest message indicating the demand for a predefined amount 
of network resources simultaneously for both directions. 

3* A method according to claim 1, 
characterized in that 

the correspondent node (106c) initiates (S3b) a resource res- 
ervation request message indicating the demand for a prede- 
fined amount of network resources simultaneously for both di- 
rections . 

4 . A method according to anyone of the claims 2 or 3 , 
characterized in that 
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the initiator (106a/c) of the resource reservation request 
message generates (S4) a unique reservation identifier (ID) 
associating the bidirectional connection to achieve a spe- 
cific forwarding behaviour which remains unchanged during the 
lifetime of the associated flow. 

5. A method according to anyone of the claims 2 to 4, 
characterized by the following steps: 

- allocating (S5) network resources by using resource control 
information piggy-packed in an IP datagram (400) . 

- monitoring (S6) these network resources or 

_ simultaneously doing both (S5+S6) at the same time for both 

directions of the resource reservation request message, 
wherein resource control information for both directions of • 
the reserved routing path is embedded in the same IP datagram 
(400) . 

6. A method according to anyone of the preceding claims, 
characterized in that 

resource control information for each direction of a reseirva- 
tion is piggybacked (S7) via resource information elements 
(400a+b) that are a part of the header extension (401c+d, 
401c'+d') of the IP datagram (400), wherein each resource in- 
formation element (400a+b) represents either a resource at- 
tribute along the reserved routing path, associated with a 
quantifiable resource metric for either one or both direc- 
tions of the flow, or a flow attribute for an individual flow 
or flow aggregate, associated with quantifiable and non- 
quantifiable flow context information either for one or both 
directions of the flow. 

7. A method according to claim 6, 
characterized in that 

said resource information elements (400a+b) describe resource 
control information for upstream direction from the initiator 
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towards the receiver or downstream direction from the re- 
ceiver towards the initiator of a resource reservation re- 
quest message or for both ditections together, wherein up- 
stream and downstream direction are uniquely identified by 
the mobile node {106a) and the correspondent node (106c) due 
to their role dn the reservation procedure either as initia- 
tor or receiver of a resource reservation request message. 

8. A method according to claim 6, 
characterized in that 

said resource information elements (400a+b) are organized in 
a modular fashion for each flow, wherein the node (106a or 
106c) that originates the resource control information deter- 
mines (S8) the number of resoxarce Information .elements 
(400a+b) to be placed into an IP datagram header (401c+d, 
401c' +d' ) . 

9. A method according to anyone of the preceding claims, 
characterized in that 

each resoiurce information element (400a+b) comprises a field 
(503) for the monitored attribute value and attribute re- 
quirement specification fields (504, 505) specifying re- 
source-attribute-specific flow requirements, which are de- 
scribed by an upper threshold defining the maximum value 
and/or a lower threshold defining the minimum value for the 
respective resource attribute. 

10. A method . according to anyone of the preceding claims, 
characterized by the following steps: 

- simultaneously monitoring (S9a) information about available 
resources for both directions of the reservation along the 
reserved routing path (alternative #1) between the mobile 
node (106a) and- the correspondent node (106c) , 
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— for every node (105b+c) along the reserved routing path 
(alternative #1) , determining (S9b) actual resource attrib- 
ute values for up- and downstream direction, 

— if at any node (105b+c) along the reserved routing path 

5 (alternative #1) a monitored resource attribute either for 

up- or downstream direction or for both directions has a 
value which is less than the correspondent monitored at- 
tribute value that is carried in the IP datagram header, 
assigning (S9c) the new value to the resource information 

10 element (400a/b) of the IP datagram header, which enables 

the receiver of the resource control information to deter- 
mine (S9d) current resource values for both directions. 

/ 

f 

11. A method according to anyone of the preceding claims, 
15 characterized by the following steps: 

— sending (SlOa) a resource reservation request message de- 
scribing a set of attribute requirement specifications and 
controlling (SlOb) the resource allocation procedure either 
for one or both directions of the resource reservation by 

20 either the mobile node (106a) or the correspondent node 

(106c) , 

— based on such a resource reservation request message, de- 
termining (SlOc) resource attribute values that should be 
allocated for the upstream direction, the downstream direc- 

25 tion or both directions at the same time by every forward- 

ing node (105b+c) along the reserved routing path 
(alternative #1) - 

12. A method according to anyone of the preceding claims, 
30 characterized in that 

resoifrce control information for different bidirectional 
flows is piggy-packed (Slla) in the same IP datagram (400) , 
wherein for each flow a reservation identifier information 
element referring to additional flow and resource information 
35 elements (400a+b) in the header of the IP datagram (400) is 
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attached (Sllb) to the IP datagram header and the grouping of 
reservation identifiers and other resource information ele* 
ments (400a+b) determines (Sllc) the membership of this in- 
formation to a specific flow. 

5 

13. A method according to anyone of the preceding claims, 
characterized in that 

either the mobile node (106a) or the correspondent node 
(106c) determines (S12) on the IP layer whether bidirectional 
10 or unidirectional resource control information can be in- 
serted into an IP datagram (400) that is ready to be trans- 
mitted to the networking interface or whether a separate IP 
datagram (400) needs to be generated for that purpose. 

15 14 . A method according to claim 13, 
characterized in that 

resource control information is placed in any IP datagram' 
(400) which follows the reserved routing path (alternative 
#1) between the initiator and the receiver of a resource res- 
20 ervation request message. 

15. A method according to anyone of the preceding claims, 
characterized by the step of 

recognizing (S13a) conditions of insufficient resources along 
25 the routing path for upstream and downstream direction at the 
correspondent node {106c) by comparing (S13b) monitored at- 
tribute values with the attribute requirement specifications 
in the resource information elements (400a+b) of an arriving 
IP datagram (400) . 

30 

16. A method according to anyone of the preceding claims, 
characterized by the step of 

setting (S14) monitored resource attribute values of specific 
resource information elements specified in the IP datagram 



P 28362 EP 



47 



header (400) to zero in case one or more forwarding nodes 
(150b+c) do not support these resource attributes. 

17. A method according to anyone of the preceding claims, 
5 characterized by the step of 

setting (S15) those attribute values carried in the IP data- 
gram header to zero that enable reser-vation end points to 
easily interpret the situation of routing asymmetry if up- 
and downstream path for a bidirectional reservation do not 
10 follow identical routes at a specific routing node (105b/c) 
along the reserved routing path (alternative #1) , 

18- A method according to anyone of the preceding claims,, 
characterized by the steps of 
15 — interpreting (S16a) resource reservation request messages 
with the value zero for one or more attribute requirement 
specifications as explicit release messages by the forward- 
ing nodes (10 5b+c) along the reserved routing path 
(alternative #1) and by the initiator or receiver of the 
20 resource reservation request messages and 

— associating (S16b) the values of these attribute require- 
ment specifications with the removal of flow- specif ic res- 
ervation state information in the forwarding nodes (105b-hc) 
along the reserved routing path (alternative #1) . 

25 

19. A method according to anyone of the preceding claims, 
characterized by the steps of 

— interpreting (S17a) resource reservation request messages 
with a value unequal to zero for one or more attribute re- 

30 quirement specifications as explicit setup messages by the 

forwarding nodes (105b+c) along the reserved routing path 
(alternative #1) and by the receiver (106c) of the resource 
'reservation request messages and 

— associating (Sl7b) the values of these attribute require - 

; 35 ment specifications with the installation of flow-specific 

\ 

I 
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reservation state information in the forwarding nodes . 
(idsb+c) along the reserved routing path (alternative #1) . 

20. A method according to anyone of the preceding claims^ 
5 characterized by the steps of 

— piggy-packing (SlBa) a flow information element specifying 
the type of reservation as either bidirectional or unidi- 
rectional in the IP datagram header (401c+d, 401c' +d') of a 
reservation setup message, 
10 — interpreting (SlBb) this flow information element at the 
foarwarding nodes (105b+c) along the reserved routing path 
(alternative #1) to ensure correct installation of reserva- 
tion state information. / 
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Abst:ract 



A mechanism for a bidirectional QoS reservation procedure 
within an in-band signaling mechanism gives symmetric real- 
time services running on mobile devices, which are used to 
support different access technologies in dynamic, mobile, 
wireless IP networks where the quality of the node connectiv- 
ity can sometimes be unpredictably time-varying, the possi- 
bility to mutually reserve, monitor and adapt QoS resources 
and service parameters for up- and downstream direction along 
a communication path. The proposed solution thereby optimizes 
conventional QoS reservation mechanisms, especially for adap- 
tive real-time services in wireless and wireless ad-hbc net- 
works, by making use of a dynamic bidirectional QoS reserva- 
tion in-band signaling approach. The expression „ in-band*^ re- 
fers to a situation where sejparation between control arid user 
plane data is abandoned. 

One embodiment of the invention pertains to a bidirectional 
quality-of -service (QoS) reservation method for managing net- 
work resources and/ or service parameters needed for symmet- 
ric real-time multimedia applications and/ or data services 
running on a mobile node (10 6a) and its correspondent node 

(106c) by signaling resource control information in both di- 
rections along specific routing paths between these nodes 

(106a, 106c) through an IP-based dynamic mobile ad-hoc net- 
work (104) . Thereby, resource control infozTtiation to be 
transmitted between the mobile node (106a) and the correspon- 
dent node (106c) is embedded (SI) in an IP datagram (400) 
which is sent via the routing path of the reserved connection 
for these nodes (106a+c) , and resource control information is 
disseminated (S2) between the mobile node (106a) and the cor- 
respondent node (106c) by using the same routing path 
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(alternative #1) through the network (X04) hop-by-hop in both 
directions . 



(Figs. 2+3) 
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